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ABSTRACT 

As the most competitive solution for next-generation net¬ 
work, software-defined network (SDN) and its dominant im¬ 
plementation OpenFlow, are attracting more and more inter¬ 
ests. But besides convenience and flexibility, SDN/OpenFlow 
also introduces new kinds of limitations and security issues. 
Of these limitations, the most obvious and maybe the most 
neglected one, is the fiow table capacity of SDN/OpenFlow 
switches. 

In this paper, we proposed a novel inference attack tar¬ 
geting at SDN/OpenFlow network, which is motivated by 
the limited fiow table capacities of SDN/OpenFlow switches 
and the following measurable network performance decrease 
resulting from frequent interactions between data plane and 
control plane when the fiow table is full. To our best knowl¬ 
edge, this is the first proposed inference attack model of this 
kind for SDN/OpenFlow. We also implemented an inference 
attack framework according to our model and examined its 
efficiency and accuracy. The simulation results demonstrate 
that our framework can infer the network parameters (fiow ta¬ 
ble capacity and fiow table usage) with an accuracy of 80 % 
or higher. These findings give us a deeper understanding of 
SDN/OpenFlow limitations and serve as guidelines to future 
improvements of SDN/OpenFlow. 

Categories and Subject Descriptors 

C.2.0 [Computer-Communication Networks]: Se¬ 
curity and protection 

Keywords 

SDN, inference attack, information leakage 

1. INTRODUCTION 

By decoupling the control plane from the data plane. 
Software-Defined Network (SDN) makes programmabil¬ 
ity a built-in feature for networks, thereby introducing 
automaticity and flexibility to the networking manage¬ 
ment. SDN has therefore been foreseen as the key tech¬ 
nology that enables the next generation of networking 


paradigm. Despite its promise, one of the most signifi¬ 
cant barriers towards SDN’s wide practical deployment 
resides in overwhelming security concerns. Therefore, 
proactively detecting, quantifying, and mitigating its 
security vulnerabilities becomes of fundamental impor¬ 
tance. 

In spite of its novelty, SDN indeed reuses various 
design and implementation elements ranging from ar¬ 
chitectures and protocols to systems from traditional 
network. It is not surprising that SDN inheres the vul¬ 
nerabilities intrinsic to these elements. For example, 
similar to any networked service, secure channels be¬ 
tween controllers and switches might be disrupted by 
DDoS attacks; like firewall rules, the flow entries may 
also conflict with each other, leaking unwanted traffic; 
malicious arp spoofing generated by attackers may poi¬ 
son the controller MAC table, disturbing the normal 
topology information gathering and packet forwarding; 
untrusted applications may instrument SDN controller 
to perform malicious behaviors without proper access 
control, which is one of the design objectives for mod¬ 
ern operating systems. In response, existing research in 
the context of SDN security mainly focuses on detect¬ 
ing and mitigating these vulnerabilities. For example, 
evaluates man-in-the-middle attacks that target at 
SDN/OpenFlow secure channels; FortNOX brings 
security enforcement module into NOX and enables 
real-time flow entry conflict check; VeriFlow detects 
network-wide invariant violations by acting as a trans¬ 
parent layer between control plane and data plane. 

In this paper, we introduce a novel SDN vulnerabil¬ 
ity. The novelty of this vulnerability stems from the 
feedback-loop nature of SDN, a fundamental difference 
compared with traditional networks. 

Specifically, most commercial SDN/OpenFlow switches 
have limited flow table capacities, ranging from hun¬ 
dreds to thousands [^. Such capacity is usually insuf¬ 
ficient to handle millions of flows that are typical for 
enterprise and data center networks [^. Nevertheless, 
the flow table capacity was just considered as a po- 
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tential bottleneck of resource consuming attacks in the 
past, motivating researches on flow caching systems like 
[zl> i and [^. But according to our analysis, the flow 
table capacity can lead to inference attack and privacy 
leakage under certain circumstances. 

As a consequence of flow table overflow, the SDN 
controller needs to dynamically maintain the flow table 
by inserting and deleting flow entries. The maintain¬ 
ing process typically include packet information trans¬ 
ferring, routing rule calculation and flow entry deploy¬ 
ment, which leads to measurable network performance 
decrease. 

Particularly, once the flow table is full, extra interac¬ 
tions between controller and switch are needed to re¬ 
move certain existing flow entries to make room for 
newly generated flow entries, resulting in further net¬ 
work performance decrease. An attacker can therefore 
leverage the perceived performance change to deduce 
the internal state of the SDN. To be more specific, we 
consider the scenario that an attacker resides in a net¬ 
work that is managed by a SDN. The attacker can then 
actively generate network traffic, triggering the interac¬ 
tions between the controller and switch with respect to 
flow entry insertion and deletion. The attacker can then 
measure the change of the network performance to es¬ 
timate the internal state of the SDN including the flow 
table capacity and flow table usage. We have designed 
innovative algorithms to exploit this vulnerability and 
quantify their effectiveness on exploiting this vulnera¬ 
bility based on extensive evaluation. 

To summarize, in this paper we made the following 
contributions: 

• We have identified a novel vulnerability introduced 
by the limited flow table capacities of SDN/OpenFlow 
switches and formalized that threat. 

• We have designed effective algorithms that can 
successfully exploit this vulnerability to accurately 
infer the internal states of the SDN network in¬ 
cluding flow table capacity and flow table usage. 

• We have performed extensive evaluation to quan¬ 
tify the effectiveness of proposed algorithms. The 
experimental results have demonstrated that the 
discovered vulnerability indeed leads to significant 
security concerns: our algorithm can infer the net¬ 
work parameters with an accuracy of 80% or higher 
across various network settings. 

The rest of this paper is organized as follows. Section 
gives an overview of some background information. 
Section gives an overall statement of the inference at¬ 
tack problem. Section and give detailed inference 
algorithms targeting at FIFO and LRU replacement al¬ 
gorithms respectively. Section gives a detailed eval¬ 
uation of the simulation results. Section [7| is a brief 


discussion about our findings and future research. Fi¬ 
nally, section 1^ concludes this paper. 


2 . BACKGROUND 

2.1 Software-Defined Network 


Software Defined Network (SDN) is a competitive so¬ 
lution for next-generation network. SDN offers network 
programmability by separating the control plane from 
the data plane. Network functions like routing calcu¬ 
lation and link discovery are extracted from switches 
(data plane) and implemented by centralized controllers 
(control plane). OpenFlow 10 is the most prominent 
SDN implementation. 

In a SDN network, the controller gathers network 
topology information and makes high-level routing deci¬ 
sions while the switches only perform the functionality 
of packet forwarding according to routing rules assigned 
by the controller. The dedicated link connecting con¬ 
troller and switch is called secure channel. Controller 
and switch communicates via secure channel using the 
OpenFlow protocol. Controller also exposes network 
control APIs or north-bound interfaces so network ad¬ 
ministrators can write their own network management 
applications to more effectively run their networks. 


2.2 SDN Datacenter Network 

The decoupled nature of SDN introduces programma¬ 
bility, automaticity and flexibility to the networking 
management, making SDN a popular solution for large- 
scale datacenter networks. Figure is a network struc¬ 
ture comparison showing the difference between tradi¬ 
tional datacenter network and SDN-based datacenter 
network. 




SDN Datacenter 


Figure 1: SDN/OpenFlow Structure 

In traditional datacenter network, the administra¬ 
tor needs to configure switches separately. Switches 
from different vendors with different managing tools be¬ 
come a major obstacle in network management. What’s 
worse, each switch only handles a fragment of the whole 
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network, the lack of global network topology makes it 
impossible to optimize network traffic dynamically and 
globally. 

Compared with traditional network, SDN reveals great 
potential in datacenter networks because of its attrac¬ 
tive advantages. The SDN controller stores global net¬ 
work topology so that the network can be efficiently 
optimized. The unified network APIs provided by con¬ 
troller make it easy to perform network management. 
There have been several successful commercial deploy¬ 
ments of SDN in datacenter networks. B4 
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network 

implemented by Google utilizes SDN to schedule net¬ 
work traffic between Google’s global datacenters and 
achieves the maximum link usage of almost 100 per¬ 
cent; Microsoft deploys SWAN 12 to dynamically re¬ 


configure routing paths of network traffic to optimize 
inter-datacenter network utilization. Evaluation shows 
that SWAN can carry 60% more traffic than traditional 
network. 


2.3 Information Leakage in Datacenter Net¬ 
work 

In modern datacenter networks like Microsoft Azure 
and Amazon EG2, customer VMs are usually multi¬ 
plexed across shared physical infrastructures. Besides 
achieving a high utilization of hardware and software 
resources, this approach also introduces new vulnerabil¬ 
ities. Previously published researches have shown that 
transparently shared physical infrastructures can lead 
to potential cross-VM information leakage. 

At first glance information leakage might seem in¬ 
nocuous, but in fact it is quite useful for clever attack¬ 
ers and will bring security issues in many aspects. The 
leakage of cache miss information is used in extraction 
and inference of RSA 13 and AES 14 secret keys. 


The leakage of inter-keystroke time information can be 
used to perform recovery of the password in keystroke 
timing attack. The leakage of network topology might 
provide weapons to attackers because some attacks are 
only possible when attacker’s VM is executed on the 
same physical server with victim’s VM 15 . The leak¬ 


age of network performance information might make it 
possible for commercial spies to estimate the number 
of visitors to a co-resident server belonging to competi¬ 
tors and further infer the operation situation of their 
company. Thus information leakage in datacenter net¬ 
works is drawing more and more attentions in network 
security and privacy researches. 


2.4 Flow Table Capacity 

Elow table is a hardware structure in OpenElow switch, 
it stores hundreds to thousands of routing rules called 
flow entries. These flow entries are generated and as¬ 
signed by the controller. Every time a network packet 
arrives in the switch, the switch will look up its flow 


table to find corresponding flow entries. If there exists 
a corresponding flow entry, the switch will forward the 
network packet according to the actions associated with 
that flow entry. If there is no flow entry matching this 
network packet, the switch will send the packet to the 
controller through the secure channel, then controller 
will calculate and generate a new flow entry and assign 
it to the switch. 

Previous works typically assume that the flow table of 
each switch can hold an infinite number of flow entries, 
which makes the controller easy to design. In practice, 
however, this assumption does not hold, and the switch 
flow table capacity can become a significant bottleneck 
to scaling SDN networks. SDN/OpenElow switch flow 
tables often cannot scale beyond a few hundred entries, 
because they typically include wildcards, and therefore 
are implemented using either complex and slow data 
structures, or expensive and extremely power-hungry 
ternary content-addressable memories (TGAM). Typ¬ 
ical SDN/OpenElow switches have rather limited flow 
table capacities from 750 to 3000 flow entries while han¬ 
dling about 100,000 concurrent flows in data centers. 
The flow table capacity bottleneck leads to potential 
flow table overflow, which is unacceptable. 

Gombine the flow table capacity issue of SDN switches 
and the resource sharing phenomenon in SDN-based 
datacenter networks, we discover the possibility of per¬ 
forming inference attacks targeting at SDN vulnerabil¬ 
ities. A formalized problem statement will be given in 
next section. 

3. PROBLEM STATEMENT 

Gonsidering the wide use of SDN/OpenElow in data 
center networks, we assume the inference attack scene 
to be in a SDN-based multi-tenant datacenter network 
like Amazon EG2 or Microsoft Azure. In a SDN-based 
datacenter network, different tenants connected to the 
same switch will share the flow table space. The flow 
table capacity’s importance as key network parameter 
and the possibility of inference attack hidden behind 
the flow table sharing phenomenon make it natural for 
us to take flow table capacity as our primary inference 
target. Besides inferring intrinsic and static property 
of the switch (flow table capacity), further inference 
should be performed on the flow table usage condition 
of other tenants in the same datacenter, which reflects 
the real-time dynamic resource consuming situation in 
datacenter networks. So we choose flow table usage as 
our secondary inference target. But inferring flow table 
capacity and flow table usage is not that easy. 

As cloud computing infrastructures, data center net¬ 
works are typically well-managed and equipped with 
advanced firewalls and intrusion detection systems. In 
order to avoid triggering the IDS, we must behave like 
an ordinary tenant, which means we cannot gather sen- 


3 







sitive information or directly hack into the controller. 
What’s worse, with the constraints of passiveness and 
concealment, the available parameters for our inference 
attack are further limited. 

After analyzing current structure and implementa¬ 
tions of SDN/OpenFlow, its decoupled nature gives us 
inspiration: the interactions between control plane and 
data plane will lead to network performance decrease, 
which can be measured through performance parame¬ 
ters like round trip time (RTT). 



Figure 2: OpenFlow Packet Processing 

Flowchart 

Figi gives an overall flowchart of packet process¬ 
ing in an OpenFlow switch. The three rectangular re¬ 
gions surrounded by dotted line stand for three possi¬ 
ble packet processing branches respectively. When the 
switch encounters an incoming packet, it will parse it 
and send the parsed packet into the subsequent process¬ 
ing pipeline. 

Then as the first step of the pipeline, the switch will 
lookup its flow table to search flow entries matching the 
packet. When there is a match, the switch will directly 
forward the packet according to actions associated with 
the corresponding flow entry. This branch is illustrated 
in the innermost rectangle of fig[^ 

When there is no corresponding flow entry in the flow 
table, extra steps will be introduced into the procedure. 
Additional interactions between the switch and the con¬ 
troller will happen to acquire corresponding routing rules, 
including packet information transferring, routing rule 
calculation and flow entry deployment. The middle 
rectangle of figH illustrates this process. 

Before the switch inserts the newly generated flow 
entry, it has to check the flow table status to make sure 
that there is enough space in the flow table. When the 
flow table is full, the controller has to perform flow table 
replacement operations to make room for the upcoming 
flow entry. These operations include deciding which 
old flow entry to delete according to certain flow table 
replacement algorithm and flow entry deletion. The 
outermost rectangle in fig [^stands for this branch. 

That is exactly where the vulnerability lies. In tradi¬ 
tional networks, the switches and routers are autonomous. 


which means they can maintain their routing tables lo¬ 
cally without interacting with an external device. But 
due to the decoupled nature of SDN/OpenFlow, main¬ 
taining switch flow tables needs frequent interactions 
between switches and controllers, making it possible 
for an attacker to leverage the perceived performance 
change to deduce the internal state of the SDN network. 

As shown in fig[^ the rectangular regions surrounded 
by dotted line correspond to different possible packet 
processing branches. The larger a rectangle is, the longer 
the processing time of that branch will be because of 
the extra steps that rectangle contains. When there is 
a match in the flow table, the processing time will be 
the shortest; when there is no match in the flow table 
and the flow table is not full, the processing time will be 
longer because of addition routing calculation and flow 
entry deployment; when there is no match in the flow 
table and the flow table is full, the processing time will 
be the longest because a flow table replacement opera¬ 
tion has to be performed. So as a network parameter 
directly influenced by the processing time, the RTT of 
a packet can serve as an indicator of flow table state 
and flow entry state. 

The process of deciding RTT thresholds for flow table 
state detection is shown in figure 




Figure 3: RTT Measurement of Different Flow 
Table State 

The two sub-figures in figure represent two cooper¬ 
ating threads, the x-axis represents the packet sequence 
and the y-axis represents the recorded RTT of every 
packet. Firstly, in the upper thread, we generate a 
packet with a specific {src_ip, dst_ip, src_mac, dst_mac} 
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combination, calling it Pkti. Send Pkti to the target 
OpenFlow switch and record the corresponding RTT as 
T 2 . Currently there is no corresponding flow entry in 
the OpenFlow switch because Pkti is a new packet. Af¬ 
ter a time span T5'i, send Pkti to the target OpenFlow 
switch again and record the corresponding RTT as Ti. 
If TSi is chosen properly, the newly installed flow en¬ 
try matching Pkti should still exist in the OpenFlow 
switch. Next, in the lower thread, we continuously gen¬ 
erate packets Pkt 2 ^ Pkts^ • • • Pktjsf, each with a differ¬ 
ent combination of {srcTp, dst_ip, src_mac, dst_mac}, 
and send these packets to the target OpenFlow switch 
with the time span of T 5 ' 2 - Because there are no flow 
entries matching there packets in the OpenFlow switch, 
the recorded RTTs will be approximately the same as 
T 2 . Keep generating and sending packets until we ob¬ 
serve a sudden increase of the RTT, which indicates 
that the flow table is full. Then in the upper thread 
we send Pkti again immediately and record the RTT 
as T 3 . To achieve higher precision, we can repeat the 
process and use average values of Ti , T 2 and T 3 as final 
results. 

From the process above we can see Ti, T 2 , T 3 will 
serve as thresholds for flow table state detection: when 
the measured RTT is around Ti , we can infer that there 
is corresponding flow entry in the flow table; when the 
measured RTT is around T 2 , we can infer that there 
is no corresponding flow entry in the flow table and 
the flow table is not full; when the measured RTT is 
around T 3 , we can infer that there is no correspond¬ 
ing flow entry in the flow table and the flow table is 
full. The measured RTT thresholds corresponding to 
different flow table states are shown in table [T] 


Table 1: RTT Comparison 


Flow Table State 

Flow Entry State 

RTT 

NotFull 

Exist 

0.2 — 0.3ms 

NotFull 

Not Exist 

3 — bms 

Full 

Exist 

0.2 — 0.3ms 

Full 

Not Exist 

8 — 10ms 


Having got a method to detect flow table state and 
flow entry state using the bootstrap process above, our 
inference model will follow a ” probe-observe-infer” pat¬ 
tern. We model the SDN/OpenFlow network as a black 
box and observe its response (RTT) to different input 
(network packets), then we use the response to estimate 
the flow table state and flow entry state and perform 
further inference. The whole process comes in three 
steps. 

Firstly, we send probing packets into the network to 
trigger the interaction. As there is still no mature rout¬ 
ing aggregation algorithm or hierarchical routing rule 


solution, current SDN/OpenFlow switches typically use 
exact-match rules. That means if we send n packets 
with different faked meta information like srcTp and 
dst_ip, there will be n newly generated flow entries in¬ 
serted into the flow table. If we send excessive probing 
packets in a short period of time, the flow table will 
overflow and then the interaction process will be trig¬ 
gered. Secondly, we measure RTTs of the responded 
packets and infer the flow table state and flow entry 
state. Thirdly, we use observed flow table states and 
flow table states as controlling signals in our inference 
algorithm and perform flow table capacity inference. 

But there is still one problem: how will the flow ta¬ 
ble deal with the flow entries when the flow table is 
full. In other words, we need to know the flow table 
replacement algorithm. The algorithm decides the in¬ 
ternal state transition of a SDN network thus it’s an es¬ 
sential part of our inference model. Though flow table 
replacement algorithms of commercial SDN/OpenFlow 
switches are stored in their firmwares, making it impos¬ 
sible for researchers to read, we can still get illumina¬ 
tions of what the algorithms will be like by analyzing 
the functionalities of flow tables. 

Flow table in a SDN/OpenFlow switch stores the lo¬ 
cal router tables assigned by the controller. Having to 
achieve a hit rate as high as possible in a rather lim¬ 
ited space, flow table serves like a ’’cache” in operating 
systems and web proxy servers. So we have reason to 
believe that the flow table replacement algorithm will be 
some of the most popular cache replacement algorithms 
or their variations. In this paper we choose FIFO 16 
and LRU 17 because they are common and popular. 

So far we have finished our inference model targeting 
at flow table capacity and there is still another target: 
flow table usage inference. Though flow table usage in¬ 
ference seems impossible because network traffic is iso¬ 
lated among different tenants, the information leakage 
attack mentioned in section and our previous analysis 
provide us with possible breakthrough points: we can 
infer the flow table capacity and we can record gener¬ 
ated flow entries during a time period, the difference of 
these two values will be the flow table usage during that 
time period. 

Last but not least, we have to discuss the feasibility of 
our inference attack as well as some key parameters. In 
order to facilitate the description, we will first introduce 
the flow entry deletion mechanism of OpenFlow. 

Flow entry deletion mechanism of OpenFlow includes 
two main parts: active flow deletion invoked by con¬ 
troller and passive flow deletion invoked by timeout. 
According to OpenFlow specification, each flow entry 
has two timeout values — hard_timeout and idle_timeout. 
Hard.timeout decides how long a flow entry will live af¬ 
ter it has been inserted while idle_timeout means the 
longest time of no packet matching before a flow entry 
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is deleted. The feasibility of our inference attack will be 
associated with timeout values and the feasibility analy¬ 
sis consists of two parts: RTT bootstrap feasibility and 
probing feasibility. 

3.1 RTT Bootstrap Feasibility 

In RTT bootstrap process illustrated in figurej^ there 
are three key parameters: T5'i, T 5'2 and TSs . Both TSi 
and TSs should not exceed the minimum of hard_timeout 
and idle_timeout because we must prevent the flow en¬ 
try matching Pkti from being deleted in the whole pro¬ 
cess, which depends on TSi and TSs respectively. In 
order to shorten TS' 3 , TS 2 should not be too long be¬ 
cause its the time span between every packet and TSs is 
made up of (n — 1) numbers of TS' 2 . In conclusion, the 
feasibility constraints for RTT bootstrap are as follows: 

(n - 1 )TS 2 = TSs ( 1 ) 

TSi < min{hard-timeout^ idle-timeout} ( 2 ) 
TSs < min{hard-timeout^ idle-timeout} (3) 

3.2 Probing Feasibility 

The key part of our inference model is triggering in¬ 
teractions between switches and controllers by sending 
probing packets in a short period of time, so the feasi¬ 
bility of our inference attack depends on the feasibility 
of triggering flow table overflow to a large extent. If we 
use Vgen to represent our packet generating speed and 
use Vdei to represent the packet deletion speed and C, 
T to represent the flow table capacity and the probing 
time, the feasibility formulation will be: 

Vgen xT-VdelXT>C (4) 

Or in another form: 

Vgen > Vdel + C/T (5) 

As can be seen from the formulation, the minimum 
packet generating speed required are associated with 
the flow entry deletion speed and flow table capacity. If 
we set T to be shorter than the minimum of hard_timeout 
and idle_timeout, which means our inference can be 
completed in a timeout circle, the flow entries deleted 
during our inference due to timeout will be ignorable. 
The feasibility constraint will be: 

Vgen ^ C/min{hard-timeout, idlo-Umeout} ( 6 ) 

From the feasibility constraints above, we can con¬ 
clude that the feasibility of our inference attack depends 


on the timeout measurement. It is essential for us to 
measure hard_timeout and idle_timeout not only for in¬ 
ference time limit but also for packet generating speed 
adjustment. 

Idle_timeout can be measured by sending a train of 
packets with gradually increasing packet intervals. The 
process is shown in Figure]^ 



Packet Sequence 

Figure 4: Idle_timeout Measurement 

We choose an initial value of packet interval ATi, for 
example 0.1s. Then we gradually increase the packet 
interval to AT 2 , AT 3 and so on using ’’binary search” 
or other algorithms. Keep sending these packets with 
increasing intervals until we observe a significantly high 
RTT value. The corresponding packet interval at that 
time will be the idle_timeout. 

HardTimeout can be measured by sending a train of 
packets with constant packet intervals far smaller that 
the previously measured idlcTimeout. Keep sending 
packets with a packet interval of AT, for example 0.1s. 
When observing a significantly high RTT value, the 
corresponding packet interval will be the hard_timeout. 
The process is shown in Figure 



Packet Sequence 

Figure 5: Hard_timeout Measurement 

In this section we set our inference targets to be flow 
table capacity and flow table usage, we also discussed 
the inference model and its feasibility. In section]^ and 
we’ll give detailed descriptions of inference algorithms 
for FIFO and LRU respectively. 

4. FIFO INFERENCE ALGORITHM 
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As mentioned in section the inference process of 
FIFO algorithm will be as follows: we generate and 
send a huge amount of probing packets each with a dif¬ 
ferent combination of src_ip, dst_ip, src_mac, dst_mac, 
the newly inserted flow entries matching the generated 
packets will ’’push” the other users’ flow entries out of 
the flow table. We can detect if the flow table is full 
and the existence of our flow entries. Combined with 
the number of inserted flow entries we recorded, we can 
infer the flow table capacity and flow table usage. The 
process of flow table state transformation is shown in 


figure 
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Figure 6: FIFO Inference Principle 


We use Four lo represent the number of our inserted 
flow entries and use Pother to represent the number of 
flow entries from other users in the flow table. Both 
Four and Pother are functions of time. We use Ta^ Tb^ 
Tc and Td to represent four time points corresponding 
to four sub figures respectively and use C to respresent 
the flow table capacity. 

Figure]^ (A) shows the flow table and the flow entries 
it contains just before the experiment starts. The rect¬ 
angle items represent the flow entries from other users 
sharing the OpenFlow switch. The current number of 
other users’ flow entries can be expressed as Pother{T a)- 

Figure (B) illustrates the time when we start to 
send generated packets, inserting new flow entries into 
the flow table. The grey rectangles represent the flow 
entries inserted by us. As we can see, our flow entries 
keep pushing other users’ flow entries to the front of 
the FIFO queue. During the experiment, we should 
keep a record of the generated packets, including their 
attributes and serial numbers. 

Figure]^ (C) shows the time when we detect the flow 
table is full. At this point of time, flow entries from 
us and other users add up to fill the whole flow table 
precisely. We have: 


Four{Tc) + Pother {Tc) = C (7) 

Figure (D) shows the time when we detect that 
one of our inserted flow entries has been deleted. That 
means the flow table is now full of our flow entries. 


without any flow entries from other users. We have: 

TouriTo) = C ( 8 ) 

Combine the two equations above, we have: 

Fother{TA) = Pother {Tc) 

= C — Four{Tc) = Tour{TD) “ Four{Tc) 

According to the analysis above, we describe the in¬ 
ference process for FIFO algorithm as shown below. 


Algorithm 1 FIFO Inference Algorithm 

Require: 

1: Packet-Sending Function: SendPacket {); 

2: List of IP: IP; 

Ensure: 

3: The flow table capacity: Fcapaeity] 

4: The number of other users’ flow entries: Pother] 

Toupaeity 0 
6 : Pother ^ 0 
7: A ^ 0 

8 : Ni i — 0 
9: N 2 — 0 

10: while N < length{IP) do 
11: ip ^ IP[N] 

12: SENDPACKET(ip) 

13: N ^ N Pl 

14: if Flow table is full then 

15: Ni ^ N 

16: continue 

17: end if 

18: if One of our flow entries is deleted then 

19: N2^ N 

20: break 

21: end if 

22: end while 

23: Feapaeity ^2 

24: Pother ^ N 2 — Ni 

25: return Feapaeity 1 Fother 


The main error of the inference comes from the flow 
entries inserted by other users when our insertion is in 
progress. We assume that our flow entry insertion speed 
is fast enough so that during the period of experiment, 
the newly inserted flow entries are all from us. But 
that is not always the truth. Ignoring the possible flow 
entries inserted by other users will make our inference 
result smaller than the actual value. 

Considering the flow entries inserted by other users, 
the actual equations are listed below. 

When we detect the flow table is full, if we use F{A, B) 
to represent the number of just inserted flow entries 
from other users from time point A to time point 5, 
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the equation becomes: 

Four{Tc) + Fother{Tc) + F{Ta, Tc) = C (10) 

And when we detect one of our inserted flow entries 
is deleted, the equation becomes: 

Four{TD) + E{Ta, Tc) + E{Tc, To) = C (11) 

Combine the two equations above, we have: 

Father {Tc) — Four {Td) - FourCc) + E{Tc, Td) (12) 

So the actual equation considering flow entry inser¬ 
tions during inference should be: 


Algorithm 2 Rolling Maintaining Algorithm 

Require: 

1 : Packet-Sending Function: SendPacket{); 

2 : List of Inserted IP: IPinserteT 

3: function ROLLINGPACKETSENDER(/P^nserted) 
4: i^l 

5: while i < length{IPinserted) do 

6: for j 4- 0; j < j + + do 

-^-Pinserted [j] 

8: SENDPACKET(ip) 

9: end for 

10 : i ^ i pi 

11: end while 

12: end function 


c = FouriTo) + E{Ta, Tc) + P(Tc, Td) 

Father {Tc) = Four{TD) Four {Tc) + EiTc,TD) 

(13) 

Compared with our former equation ignoring flow en¬ 
try insertions: 


C = FouriTn) 

Father {Tc) Four {Td) Four {Tc) 


(14) 


We can see that the inferred flow table usage Father 
and the inferred flow table capacity Fcapaeity will both 
be smaller than the actual value. 


5. LRU INFERENCE ALGORITHM 

The experiment principle of LRU algorithm has some¬ 
thing in common with that of FIFO algorithm, because 
under these two circumstances we can both keep our 
flow entries stay in the back of the cache queue using 
certain operations.However, there are still differences 
lies in the flow entry maintaining process. 

The nature of FIFO algorithm ensures that the posi¬ 
tion of the flow entries only depends on the time they 
are inserted. The earlier inserted flow entries are sure 
to be nearer to the front of the cache queue compared 
with the later inserted flow entries. But in LRU algo¬ 
rithm, the positions of the flow entries depend not only 
on the time they are inserted, but also on the last time 
they are accessed. In order to keep our flow entries stay 
in the back of the cache queue, we need to continuously 
access the previously inserted flow entries. 

During the maintain process, every time we insert 
a new flow entry, we need to access all previously in¬ 
serted flow entries for one time to ’’lift” them to the 
back of the cache queue. The access history may be like 
{PA {Pi, P 2 }, {Pi, P2, P3}, (Pi, P2, P3, PA---, 
we call it a ’’rolling” maintaining process. The main¬ 
taining algorithm is shown in algorithm 2 . 


According to the analysis above, we describe the in¬ 
ference process for LRU algorithm as shown below. 


Algorithm 3 LRU Inference Algorithm 

Require: 

1: Packet-Sending Function: SendPacket {); 

2: List of IP: IP; 

Ensure: 

3: The flow table capacity: Fcapaeity] 

4: The number of other users’ flow entries: Father] 

Fcapaeity 0 
6: Faiticr 0 

7: A ^ 0 
8 : Ai ^ 0 
9: A 2 ^ 0 

10: I Pinserted [ ] 

11: while N < length{IP) do 
12 : ip ^ IP[N] 

13: I Pinserted I Pinserted T 

14: ROLLINGP ACKETSeNDER{I Pinserted) 

15: N^NPI 

16: if Flow table is full then 

17: Ni^N 

18: continue 

19: end if 

20: if One of our flow entries is deleted then 

21 : N2^ N 

22: break 

23: end if 

24: end while 

25: Fcapaeity F^2 

26: Father ^ ^2 ~ 

27: return Fcapaeity-) Father 


The feasibility and error analysis of LRU algorithm is 
similar with that of FIFO algorithm. The inferred flow 
table usage Father and the inferred flow table capacity 
Fcapaeity will both be Smaller than the actual value be- 
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cause of ignoring the flow entries inserted by other users 
during the experiment. 

6. EVALUATION 


6.1 Implementation 

The emulation environment of our experiment con¬ 
sists of three parts: a network prototyping system used 
to emulate host and switch, a network controller, and 
our inference attack toolkit. 

We choose Mininet 


18 as the network prototyping 


system because it encapsulates host and switch emu¬ 
lation and thus easy to use. Our emulated network 
prototype for evaluation uses a star topology, consist¬ 
ing of 20 hosts connected to a single OpenFlow switch. 
We build FIFO and LRU controller applications using 
Python on the basis of POX 19 OpenFlow controller. 
As for the inference attack toolkit, we use libnet 20 to 
generate probing packets, and libpcap to capture 
replied packets. Experiments are conducted on a com¬ 
puter with Intel 15-2400 3.1 GHz (4 cores) processor and 
8GB RAM. 


6.2 RTT Measurement 

As we have mentioned in section the difference be¬ 
tween traditional network and SDN/OpenFlow network 
in handling previously unseen packets gives us a possi¬ 
ble indicator of the flow table state and the flow entry 
living state - RTT. When there isn’t corresponding flow 
entry existing in the flow table, the RTT of a packet will 
significantly increase due to the interactions between 
controller and switch in order to acquire new flow en¬ 
tries. That is the case when there is still space in the 
flow table. Once the flow table is full, the RTT of a 
packet will further increase as a result of extra flow ta¬ 
ble replacement operations. To prove the effectiveness 
of using RTT as the flow table state and flow entry state 
indicator, we measured packet RTTs corresponding to 
different flow table state and flow entry state. 


sent the total 300 times of RTT measurements we have 
conducted, 100 times of measurement for each combi¬ 
nation of flow table state and flow entry state. The 
green points stand for RTTs when flow entry exists in 
flow table. The blue points and red points both stand 
for RTTs when flow entry doesn’t exist in flow table, 
the only difference is the flow table is not full when 
measuring the blue points. 

As can be seen from the figure, when flow entry ex¬ 
ists in flow table, the packet RTTs are highly concen¬ 
trated in the range of 0.2 ^ 0.3 ms; when flow entry 
doesn’t exist in flow table and flow table is not full, the 
packet RTTs will increase to about 3 ^ 5 ms; when 
flow entry doesn’t exist in flow table and flow table is 
full, the packet RTTs will be the highest, ranging from 
6ms to 8ms. These three groups of RTTs all distribute 
intensively in a small range without overlapping other 
groups, showing the excellent discrimination of using 
RTT as a flow table state and flow entry state indica¬ 
tor. 

To better illustrate the distribution of measured RTTs, 
we plot their CDF curves in figure Apparently RTT 
can be used to deduce the internal state of the SDN 
network effectively. 
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Figure 8: RTT Measurement Distribution 

6.3 Timeout 



Group 


Figure 7: RTT Measurement 

Figure gives the RTT measurement result showing 
the difference. The points with different colors repre¬ 


6.3.1 Default Timeout Values 

According to our previous analysis, the feasibility of 
our inference attack depends on whether we can gener¬ 
ate enough flow entries to fulfill the flow table within 
a single timeout cycle. That means we must have the 
ability to generate as many flow entries as the flow en¬ 
try can hold during a timeout period. So we analyze 
several popular open-source controllers and search for 
their default timeout values in the built-in applications. 
The result is presented in table The zero values in 
the table mean the corresponding timeout will not take 
effect, or in other words the timeout value is ’’perma¬ 
nent”. As can be seen from the table, most available 
controllers have timeout values in the range of 5s to 30s. 

If we take the flow table capacity of 2000 flow entries 
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Table 2: Default Timeout Values 


Controller 

Hard Timeout 

Idle Timeout 

Ryu 

0 

0 

Beacon 

0 

5s 

Floodlight 

0 

5s 

NOX 

0 

5s 

POX 

30s 

10s 

Trema 

0 

60s 

Maestro 

180s 

30s 


as an example, the minimum packet generating speed 
required will be 2000/5 = 400 packets per second, while 
libnet can generate tens of thousand packets per second. 
So the default timeout values ensure the feasibility of 
our inference attack. 


Flow capacity is the primary target of our inference 
attack. It reflects the hardware specification of an Open- 
Flow switch. Figure [To] illustrates the flow table capac¬ 
ity measurement result when controller adopts FIFO re¬ 
placement algorithm. We manually limited the switch 
flow table capacity to 10 different values from 100 flow 
entries to 1000 flow entries and used our framework to 
perform the inference. 
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6.3.2 Timeout Measurement 

Though default timeout values of mainstream Open- 
Flow controllers can be read from their source codes, it’s 
still possible for SDN network administrators to man¬ 
ually change the default timeout values. In order to 
handle non-default timeout values and provide basis for 
adjusting packet generating speed, it’s essential to ex¬ 
amine the accuracy of passive timeout measurement. 

Figure illustrates relative errors of hard_timeout 
and idle_timeout measurement respectively. We man¬ 
ually modify hard_timeout and idle_timeout values of 
POX OpeuFlow controller to 5s, 10s, 15s, 20s, 25s and 
30s, then we use timeout measurement algorithm men¬ 
tioned in section [ 3 ] to measure these timeout values and 
calculate relative errors. 


Hard-Timeout Relative Error 



Idle-Timeout Relative Error 


— Timeout = 30 

— Timeout = 25 

— Timeout = 20 
Timeout = 15 

— Timeout = 10 

— Timeout = 5 
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Figure 9: Timeout Relative Error 


Every line in the two sub-figures corresponds to 10 
times of repeated measurements conducted under a cer¬ 
tain timeout setting from 5s to 30s. The margin stays 
in the range of plus-or-minus 10 percent, showing the 
effectiveness and high accuracy of our timeout measure¬ 
ment algorithm. 


Figure 10: FIFO Flow Table Capacity 

The pink bars represent the manually set flow table 
capacities or real capacities. The blue bars represent 
the measured flow table capacities. For every manually 
set flow table capacity, we conduct 10 times of repeated 
measurements and take their mean value as the final 
result. From the figure we can see that the measured 
capacities is quite close to the real capacities, indicat¬ 
ing the high accuracy of our inference framework. For 
example, when the real capacity is 400 flow entries, our 
measured capacity is 408 flow entries with an error of 
only 8 flow entries. As the real capacity grows, the 
packet generating speed required becomes faster, plac¬ 
ing higher requirements on packet sending - receiving 
synchronization and accurate timing. But our infer¬ 
ence algorithm shows unbelievable stability and accu¬ 
racy: when the real capacity is 1000 flow entries, our 
measured capacity is 973 flow entries with an error of 
just 27 flow entries. 

Like figure figure pT] also illustrates the flow table 
capacity measurement results, with the only difference 
of being performed under LRU replacement algorithm 
instead of FIFO. 
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6.4 Flow Table Capacity 


Figure 11: LRU Flow Table Capacity 
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According to our previous analysis, the inference prin¬ 
ciple of LRU replacement algorithm is more complex 
because of the unavoidable mixed nature of flow entries 
in the flow table and the rolling maintaining process. 
But our inference framework still shows high accuracy 
and reliability. Even when the real flow table capacities 
are set to be rather large values like 900 and 1000, the 
errors of our measure capacities are just around 20 flow 
entries. 

Only illustrating the mean value of measured flow ta¬ 
ble capacities may not be enough: the mean value may 
be the result of error compensations and hide the de¬ 
tailed measurement errors of every separate experiment. 
So in figure we illustrates the relative error of every 
single flow table capacity measurement. 


FIFO Capacity Relative Error 
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Figure 12: Flow Table Capacity Relative Error 


We choose 5 groups of different flow table capacities 
from 200 flow entries to 1000 flow entries and perform 
10 times of measurements under every single flow table 
capacity value. The left sub-figure stands for relative 
error of flow table capacity measurements conducted 
under FIFO replacement algorithm, showing that the 
margin is no larger than plus-or-minus 10 percent. The 
right sub-figure stands for relative error of flow table 
capacity measurements conducted under LRU replace¬ 
ment algorithm. Due to the more complex inference 
principle and the rolling maintaining process, the mar¬ 
gin becomes larger but still hasn’t exceeded 15 percent 
even in the worst case. 


6.5 Flow Table Usage 

In this section we evaluated our framework’s efficiency 
of inferring the number of flow entries from other users 
sharing the same flow table, or the flow table usage. 
Flow table usage is our secondary inference target, it re¬ 
flects the network resource consuming condition of other 
tenants in the same SDN network. Figure and figure 


14 illustrate the flow table usage measurement results 


conducted under FIFO and LRU replacement algorithm 
respectively. 



Figure 13: FIFO Flow Table Usage 



Figure 14: LRU Flow Table Usage 


Again we manually set 10 different flow table usage 
values from 100 to 1000 flow entries by manually gen¬ 
erating and inserting corresponding number of flow en¬ 
tries into the flow table beforehand. Then we use our 
inference algorithm to infer the flow table usage and 
take mean values of every 10 times of measurements as 
the final results. The errors of all these measurements 


show the high accuracy, stability and reliability of our 
inference algorithm. 

The relative errors are shown in figure We em¬ 
ulate 5 groups of different flow table usage values and 
conducted 10 times of flow table usage inference for ev¬ 
ery single value. For both FIFO and LRU replacement 
algorithm, the relative errors of flow table usage infer¬ 
ence stay in a quite small range. The results prove that 
our algorithm can infer other tenants’ flow table usage 
condition in high accuracy. 


FIFO Usage Relative Error 


LRU Usage Relative Error 
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Figure 15: Flow Table Usage Relative Error 

7. DISCUSSION 
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SDN/OpenFlow has become a competitive solution 
for next generation network and is being more and more 
widely used in modern datacenters. But considering its 
key role as the datacenter fundamental infrastructure, 
we have to admit that the security issues of SDN/OpenFlow 
haven’t been explored to a large extent. Especially, the 
flow table capacity of SDN/OpenFlow switch is only 
considered as a vulnerable part for DDoS and flood¬ 
ing attacks in published researches. But according to 
our analysis in previous sections, the flow table capacity 
can lead to potential inference attack if combined with 
reasonable assumptions and RTT measurements. 

Firstly, we found in section that exact match flow 
entries as well as the lack of route aggregation would 
consume a lot of flow table space, making it impos¬ 
sible to process millions of flows per seconding using 
SDN/OpenFlow. Secondly, we found in section that 
assigning the decision making job of flow table replace¬ 
ment to the controller would lead to significant network 
performance decrease, which had to be changed in time. 
Thirdly, there is currently no mature attack detection 
mechanism for SDN/OpenFlow network, so it’s quite 
easy for criminals to exploit system vulnerabilities or 
invoke DDoS attacks. 

All these security issues call for improvements to cur¬ 
rent OpenFlow switch and flow table design. The im¬ 
provements should at least contain three aspects: (l)new 
flow table maintaining mechanism, like transferring the 
flow entry deleting workload from controller to switch. 
Switch itself can decide which flow entry to delete and 
then sync with controller. In the newest OpenFlow 
switch specification 1.4 [^, this mechanism has been 
added as an optional feature, but without any mature 
implementation so far; (2) routing aggregation. Rout¬ 
ing aggregation can match a group of flows using one 
flow entry, which will reduce the flow table consuming 
significantly compared with exact match; (3) inference 
attack detection. Administrators can develop inference 
attack detecting applications and then perform defences 
like port speed limiting or network address validation. 

8. RELATED WORK 

The inference attack proposed in this paper is moti¬ 
vated by the limited flow table capacity of SDN/OpenFlow 
switches. The flow table capacity issue has been pre¬ 
sented in many previous works like [^, and [^ . 
They all point out the limitation of switch flow table 
memory and potential scalability and security issue. 
However, these work don’t give further analysis on the 
inference attack and information leakage caused by the 
limited flow table capacity. 

Kloti et al. presents potentially problematic is¬ 
sues in SDN/OpenFlow including information disclo¬ 
sure through timing analysis. However, this informa¬ 


tion disclosure requires disclosing existing flows with 
side channel attack, which is hard to perform in real 
world. Compared with their approach, our inference at¬ 
tack is self-contained and requires no prior knowledge. 

Gong et al. 27 presents a kind of inference attack 


using RTT measurement to infer which website the vic¬ 
tim is browsing. They recover victims’ network traffic 
patterns based on the queuing side channel happened at 
the Internet router. However, the scenario of their work 
is in the public Internet, while our approach focus on 
SDN/OpenFlow infrastructures in datacenter network. 
Compared with public Internet and website inference, 
the inference attack and information leakage in modern 
data centers is more sensitive and valuable. 

Shin et al. 28 demonstrate a novel attack targeting 
at SDN networks. This attack includes fingerprinting 
SDN networks and further flooding the data plane flow 
table by sending specifically crafted fake flow requests 
in high speed. In the fingerprinting phase, header field 
change scanning is used to collect the different response 
time (RTT) for new flow and existing flow. The finger¬ 
printing result is then analyzed to estimate if the target 
network used SDN technology. The RTT measurement 
and analysis they used in fingerprinting is similar with 
our approach. But they just perform DoS attacks to 
the SDN network, without performing any further in¬ 
formation leakage or network parameter inference. 


9. CONCLUSION 

In this paper, we have explored the structure of SDN/ 
OpenFlow network and some of the possible security is¬ 
sues it brings. After out detailed analysis of the SDN/ 
OpenFlow network, we proposed a novel inference at¬ 
tack model targeting at the SDN/OpenFlow network, 
which is the first proposed inference attack model of this 
kind in the SDN/OpenFlow area. This inference attack 
is introduced by the OpenFlow switch, especially by its 
limited flow table capacity. The inference attack can 
be done in a completely passive way, making it hard 
to detect and defence. We also implemented the infer¬ 
ence attack framework and examined the efficiency and 
accuracy of it using network traffic data from different 
sources. The simulation results show that the inference 
attack framework can infer the network parameter (flow 
table capacity and flow table usage) with an accuracy 
of up to 80% or higher. 
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